직무 · 모든 회사 / 모든 직무

Q. Google OAuth drive.file 사용 시 Production 전환·서버 refresh token 정책 문의

포테토칩00

정말 간절한데 물어볼 곳이 없어요.. ㅠㅠ Google OAuth + Drive API를 사용하는 웹 앱입니다. - Google 로그인(OAuth 2.0) - 사용자 개인 Drive 사용 - scope: drive.file만 사용 - 앱이 생성한 파일만 접근 - Next.js 서버에서만 API 호출 궁금한 점은 다음입니다. drive.file만 사용해도 OAuth 동의 화면을 Production 전환 시 별도 검증이 필요한가요? (비민감 scope이므로 Sensitive/Restricted 검증은 불필요한지) OAuth로 발급된 refresh token을 Next.js 서버에 저장하고 서버에서 사용자 대신 Drive에 쓰기 작업을 하는 구조는 정책상 허용되나요? 비로그인 제3자가 폼으로 데이터를 제출하고, 서버가 사용자 refresh token으로 해당 데이터를 Drive에 저장하는 방식은 정상적인 OAuth 위임 동작인가요, 아니면 허용되지 않는 간접 접근인가요?


2026.01.13

답변 2

  • 전문상담HL 디앤아이한라
    코이사 ∙ 채택률 63%

    안녕하세요, 성실히 답변드리겠습니다. 채택바랍니다. 1. Scope 비민감 (scope만 ) > OAuth 검증 불필요, 프로덕션 전환시 구글 검증 생략 가능 2. 서버에 리프레시 토큰 저장 > 서버가 사용자 대신 API 호출 가능 > 허용됨 , 단 보안 및 암호화 필수 3. 비 로그인 제 3자가 제출 > 서버가 드라이브에 저장 Oauth 원칙상 사용자 직접 동의가 필요한 범위를 우회하는 구조로 간주될 수 있음 사용자 Consent없이 제3자 데이터를 쓰는 건 간접 접근으로 정책 위반 가능성 있음 즉 서버에서 사용자의 리프레시 토큰으로 직접 파일 쓰기는 가능하지만, 사용자 동의 없이 다른 사람 데이터를 대신 쓰는건 주의 필수입니다.

    2026.01.13


  • 프로답변러YTN
    코부사장 ∙ 채택률 86%

    멘티님 drive.file 스코프는 민감하거나 제한된 스코프가 아니므로 까다로운 보안 심사나 3등급 검증 없이 기본적인 브랜드 검증만 거치면 문제없이 프로덕션 전환이 가능합니다. Next.js 서버에 리프레시 토큰을 안전하게 저장하여 오프라인 액세스로 활용하는 것은 구글이 권장하는 표준 인증 방식이므로 정책상 완벽하게 허용됩니다. 또한 제3자의 입력값을 서버가 처리해 토큰 소유자의 드라이브에 저장하는 로직 역시 사용자가 앱에 파일 생성을 위임한 정상적인 서비스 동작이므로 정책 위반이 아닌 올바른 설계입니다. 현재 구상하신 아키텍처는 기술적으로나 정책적으로나 아무런 문제가 없으니 안심하고 그대로 개발하시면 됩니다. 채택부탁드리며 파이팅입니다!

    2026.01.07



    댓글 2

    포테토칩00
    작성자

    2026.01.07

    추가로 한 가지만 여쭙고 싶습니다. 로그인한 사용자의 Google OAuth refresh token(Drive 접근 권한) 을 URL 파라미터로 암호화/서명하여 제3자(비로그인 유저)에게 전달하고, 서버가 이를 복호화해 drive.file 스코프로 해당 사용자의 Drive에 파일을 생성·수정하는 구조는 OAuth 정책상 토큰 공유/간접 접근으로 간주되어 문제가 될 수 있는지, 아니면 정상적인 위임 동작으로 허용되는지 궁금합니다..!


    포테토칩00
    작성자

    2026.01.09

    이 부분에서는 답변이 어려우실까요..? ㅠㅠ


  • AD
    반도체
    설계팀

    대기업 반도체 산업으로 취업하기 위해선, 직관적 해석능력과 사고력이 필요합니다. 핵심 역량과 배운 지식을 취업에 활용하고 싶다면 국비지원 강의를 추천합니다.

    코멘토 내일배움카드 안내

함께 읽은 질문

궁금증이 남았나요?
빠르게 질문하세요.